The current internet protocol (IP) assigns a unique 32-bit address called an IP address to each node on the internet for enabling communication with the node. A node may be a network end-station, such as, for example, a computer, workstation, or server. The node may also be a gateway device, such as, for example, a switch or a router.
Due to the booming evolution of the internet, IP addresses have become a scarce resource. In 1996, the Internet Engineering Task Force (IETF) published a Best Common Practice describing a range of IP addresses reserved for use with private networks, described in further detail in “Address Allocation for Private Internets,” Y. Rekhter et al., IETF Request for Comment (RFC) 1918, February 1996 (hereinafter referred to as RFC 1918), the content of which is incorporated herein by reference. These addresses, known as private or nonroutable addresses, help provide a temporary solution to the depletion of globally unique IP addresses. Private IP addresses, however, are not guaranteed to be unique because they may be used by multiple nodes in different private networks. Therefore, private IP addresses are not routable over the internet.
A node having a private IP address desiring to communicate over the internet may nonetheless do so using a technology known as network address translation (NAT), described in further detail in “The IP Network Address Translator (NAT),” K. Egevang et al., RFC 1631, May 1994, the content of which is incorporated herein by reference. NAT requires a site to have a single connection to the global internet and at least one globally valid IF address. NAT translates the addresses in both outgoing and incoming data units by replacing the source address in each outgoing data unit with the globally valid IP address, and replacing the destination address in each incoming data unit with the private IP address of the correct node.
Although a private IP address assigned to a node is unique in its home site, duplicate private IP addresses may be encountered if the node is a mobile node that moves to a foreign site and remains temporarily attached there. If the private IP address is assigned to the mobile node at the home site for an extended period of time, the private IP address is referred to as the mobile node's home address. A home site may be a network or a group of networks having a network address whose prefix matches that of the mobile node's home address. A foreign network may be any network other than the mobile node's home network.
Under the existing protocol for IP routing for mobile nodes (hereinafter referred to as “mobile IP”), described in detail in “IP Mobility Support,” C. Perkins (Editor) RFC 2002, October 1996 (hereinafter referred to as RFC 2002), the content of which is incorporated herein by reference, a mobile node may move from network to network, changing its point of attachment to the internet, while continuing to be reachable through its home address. Thus, a mobile node whose home address is a private IP address maintains and uses the private IP address while visiting the foreign site. Consequently, duplicate private IP addresses may be encountered if two mobile nodes belonging to two different networks but configured with the same private IP address as their home addresses visit the same foreign site. In this case, the exact identity of the mobile node transmitting and receiving a packet becomes unclear.
According to the mobile IP protocol, a mobile node acquires a care-of address generally via a foreign agent advertisement message. A foreign agent may be a gateway device, such as, for example, a switch or a router, providing mobile IP services to the mobile node from the foreign site. The care-of address may be a foreign agent care-of address or a co-located care-of address. The foreign agent care-of address is generally the IP address of the foreign agent. The co-located care-of address is a local IP address on the foreign network assigned to the mobile node.
Once the mobile node has acquired a care-of address, it registers this address with its home agent. The home agent may be a gateway device, such as, for example, a switch or a router, providing mobile IP services to the mobile node from the home site. The home agent intercepts packets addressed to the mobile node and tunnels the packets to the care-of address at the foreign site. When the care-of address is a foreign agent care-of address, the foreign agent decapsulates and delivers the packet to the mobile node to which the packet is addressed. However, if two mobile nodes share the same private address, an ambiguity arises as to the exact recipient of the packet.
In transmitting a packet from the foreign site, the mobile IP protocol provides that the packet is to be transmitted by the mobile node via a standard IP routing protocol. However, when the mobile node is configured with a private IP address, the standard IP routing protocol is inadequate for transmitting the packet. Instead, the private address must first be translated to a globally unique IP address using NAT, and then routed over the internet.
Reverse tunneling, described in further detail in “Reverse Tunneling for Mobile IP,” G. Montenegro (editor), RFC 2344, May 1998 (hereinafter referred to as RFC 2344), the content of which is incorporated herein by reference, may provide a potential solution to the problem of using private IP addresses for transmitting packets from a foreign site. Reverse tunneling allows packets to be transmitted by the home agent on behalf of its mobile node.
In a direct delivery style of reverse tunneling, the mobile node designates the foreign agent as its default router and proceeds to send packets directly to the foreign agent, that is, without encapsulation. The foreign agent intercepts the packet and tunnels them to the home agent. The home agent may then invoke NAT to translate the private IP address and transmit the packets on behalf of its mobile node.
In an encapsulating delivery style, the mobile node encapsulates all its outgoing packets to the foreign agent. The foreign agent decapsulates and re-tunnels them to the home agent, using the foreign agent's care-of address as the entry-point of the new tunnel. The home agent may again involve NAT to translate the private IP address and transmit the packets on behalf of its mobile node.
Although reverse tunneling may be applied to allow the use of private IP addresses in transmitting packets from a foreign site, it does not extend to the situation where duplicate IP addresses are used in the same foreign site. Where such duplicate IP addresses exist, an ambiguity arises as to the home agent to which a packet is to be reverse tunneled.
One potential solution for the problem of duplicate IP addresses is the use of co-located care-of addresses instead of a foreign agent care-of address. A co-located care-of address is acquired by the mobile node as a local IP address on the foreign network either on a temporary or long-term basis, as is described in further detail in RFC 2002. When using a co-located care-of address, it is the mobile node and not the foreign agent that receives packets tunneled by its home agent. Since each mobile node is assigned to a different care-of address, the packets are tunneled to the appropriate mobile node. This solution, however, places unnecessary demands on the already limited IP address space, and is therefore undesireable.
Another potential solution to the problem of duplicate private IP addresses in foreign sites is private IP encapsulation within IP, discussed in further detail in a working draft entitled “Private IP Encapsulation within IP (PIPE),” B. Petri, January 2000, which is an extension of “IP Encapsulation within IP,” C. Perkins, RFC 2003, October 1996, the contents of both of which are incorporated herein by reference. Private IP encapsulation within IP uses a virtual private network (VPN) identifier to identify the private network to which a private IP address belongs. The VPN identifier may be attached to the private IP address to create a globally unique address that is routable over the Internet. The VPN identifier is embedded between the outer and inner IP headers of an IP packet.
Although PIPE may allow duplicate private IP addresses for mobile nodes in the foreign site, it requires that all mobile nodes with the same private IP address receive and examine an incoming packet to determine if they are the correct destination since the VPN identifier is embedded between the tunnel. This creates an extra overhead taking up air interface and/or the mobile node's battery life, both of which are considered to be scarce resources. It also severely reduces the privacy of the communication in which the mobile node is involved.
Accordingly, there is a need in the art for a system and method for efficiently resolving the ambiguity created by the use of duplicate private IP addresses in a foreign site. Such a system and method should resolve the ambiguity without placing a burden on scarce resources, whether it be IP addresses, air interface, or battery life.